Client intermediation of server applications

ABSTRACT

One embodiment of the present invention provides a method and an apparatus for providing a client-side intermediary that communicates with an application on a second server computer system. The method operates by receiving a composite message at a client computer system from a first server computer system, and examining type information from the composite message. This type information specifies how the composite message is formatted, and can be used to select an application that is capable of processing the composite message. The method uses the type information to look up a network address of the application residing on the second server computer system. This address is used to forward the composite message to the application on the second server computer system. The above embodiment can be implemented within a browser on the client computer system, or within a separate application on the client computer system. A return communication can be facilitated by receiving a return composite message at the client computer system from the second server computer system, and examining type information from the return composite message. This type information is used to look up an address of a source application on the network, and this address is used to forward the return composite message to the source application.

BACKGROUND

The present invention relates to client-server architectures indistributed computer systems. More particularly, the present inventionrelates to a method and an apparatus that operates on a client computingsystem and implements what appears to be an application located on theclient computing system, but which actually acts as a proxy far anapplication on a remote server computing system.

The recent proliferation of client-server based distributed systems hasled to the development of numerous server applications, located onserver computer systems, that interact with client applications, locatedon client computer systems. For example, one recently developed clientapplication is an "electronic wallet," which contains financialinstruments in electronic form, such as electronic cash, electronicdebit cards or electronic credit cards. An electronic wallet typicallyresides on a client computer system, and performs financialtransactions, such as purchases, by communicating with a serverapplication on a server computer system. For example, a user on a clientcomputer system might decide to purchase software from a server computersystem that belongs to a software vendor. Protocols such as the SecureElectronic Transactions (SET) protocol and the Open Trading Protocol(OTP) enable the server computer system to receive a payment for thesoftware from an electronic wallet on the client computer system. Usingthese protocols, this payment is automatically deducted from an accountlinked to the electronic wallet on the client computer system, and isautomatically credited to an account linked to an application on theserver computer system.

One problem with many existing server-based applications, as well aswith protocols such as SET and OTP, is that they are designed tointeract with a client application that resides on a client computersystem. Locating an application, such as an electronic wallet, on aclient computer system has certain disadvantages. First, an owner of theclient application may want to use the client application from a numberof different client computer systems. In this case, if the clientapplication is tied to a particular client computer system, the owner ofthe client application cannot access the client application from anotherclient computer system. Second, installing a client application, such asa wallet, on a client computer system can take up storage space on theclient computer system and may require additional maintenance on theclient computer system--to update the client application, for example.Additionally, retrieving code from a server computer system can incur along delay in downloading the code from the server computer system.

SUMMARY

The present invention allows a client application to interact withexisting server applications and protocols, and allows the owner of theclient application to use the client application from different clientcomputer systems. One embodiment of the present invention provides amethod and an apparatus for providing a client-side intermediary thatcommunicates with an application on a second server computer system. Themethod operates by receiving a composite message at a client computersystem from a first server computer system and examining typeinformation from the composite message. This type information specifieshow the composite message is formatted, and can be used to select anapplication that is capable of processing the composite message. Thistype information is used to look up an access mechanism that can be usedto access the application residing on the second server computer system.This access mechanism is used to forward the composite message to theapplication on the second server computer system. The above embodimentcan be implemented within a browser on the client computer system, orwithin a separate application on the client computer system. A returncommunication can be facilitated by receiving a return composite messageat the client computer system from the second server computer system,and examining type information from the return composite message. Thistype information is used to look up an access mechanism for a sourceapplication on the first server computer system, which is used toforward the return composite message to the source application.Receiving commands from a user at a client computer system.

Thus, the present invention allows an application on a first server tocommunicate with what appears to be an application located on a clientcomputer system. In reality, an intermediary on the client computersystems forwards the communications to an application on a secondserver. This allows a client application program, such as an electronicwallet, to be located on an accessible server on a network. This makesit possible for the owner of an application program, such as a wallet,to use the application program from different client computer systems.It additionally frees the client computer system from the burden ofstoring the application program.

BRIEF DESCRIPTION OF THE FIGURES

FIG. 1 illustrates a distributed computer system in accordance with afirst embodiment of the present invention.

FIG. 2 illustrates a distributed computer system in accordance with asecond embodiment of the present invention.

FIG. 3 is a flow chart illustrating some of the operations involved inforwarding communications to an application on a remote serveraccordance with an embodiment of the present invention.

DETAILED DESCRIPTION

The following description is presented to enable any person skilled inthe art to make and use the invention, and is provided in the context ofa particular application and its requirements. Various modifications tothe disclosed embodiments will be readily apparent to those skilled inthe art, and the general principles defined herein may be applied toother embodiments and applications without departing from the spirit andscope of the present invention. Thus, the present invention is notintended to be limited to the embodiments shown, but is to be accordedthe widest scope consistent with the principles and features disclosedherein.

The data structures described in this detailed description are typicallystored on a computer readable storage medium, which may be any device ormedium that can store code and/or data for use by a computer system.This includes, but is not limited to, magnetic and optical storagedevices such as disk drives, magnetic tape, CDs (compact discs) and DVDs(digital video discs), and computer instruction signals embodied in acarrier wave.

DESCRIPTION OF ONE EMBODIMENT

FIG. 1 illustrates a distributed computer system in accordance with afirst embodiment of the present invention. The embodiment illustrated inFIG. 1 includes server 102 coupled to server 104 and client 108 throughnetwork 106. Network 106 generally refers to any type of wire orwireless link between computers, including, but not limited to, a localarea network, a wide area network, or a combination of networks. In oneembodiment of the present invention, network 106 includes the Internet.In another embodiment, network 106 includes multiple networks, includinga local area network and the Internet. Client 108 may include any nodeon a computer network including computational capability and including amechanism for communicating across network 106. Servers 102 and 104 mayinclude any node on a computer network including computationalcapability, and possibly data storage capability, as well as a mechanismfor servicing requests from a client for computational or data storageresources.

In the illustrated embodiment, server 102 includes web server 110. Webserver 110 is an application program residing on server 102 thatfacilitates the presentation of at least one website to clients ofserver 102. To this end, web server 102 presents inter-linked pages oftext and graphical images and programs to be accessed by browsers onclient systems. (For purposes of this detailed description, a browser isa program, typically located on a client computer system, which allows auser to navigate through collections of data, such as web sites, onremote computer systems.) In the illustrated embodiment, web server 110is accessible from any browser coupled to the World Wide Web via theInternet. Although the illustrated embodiment operates in the context ofa web server 110 and a web browser 114, the present invention will workfor numerous types of client programs and server programs, and is notlimited to just web servers and web browsers.

Application server 104 contains application 112, which receivescommunications from client 108, and performs operations that appear tobe performed by an application located on client 108. In one embodimentof the present invention, application 112 includes code and data toimplement an electronic wallet on application server 104. (For purposesof this detailed description, an electronic wallet is a collection offinancial instruments, such as credit cards, debit cards and cash inelectronic form, possibly stored on a smart card. An electronic walletis typically implemented through an application program that performstransactions on the financial instruments.) In general, application 112may implement any type of application, not only an electronic wallet.Note that application 112 can receive communications from other clientsbesides client 108. This allows the owner of an application, such as awallet, to use the application from different clients. It also allowsthe server to act as a client for multiple users.

Client 108 includes web browser 114, mediator 120 and table 122. Webbrowser 114 includes code and data that allows a user on client 108 tonavigate through web pages located on servers distributed across network106. One example of such as browser is Netscape Navigator 3.0, producedby the Netscape Communications Corporation of Mountain View, Calif. Inthe illustrated embodiment, web browser 114 contains table 116, whichincludes translations from type information to identifiers forapplications, as well as table 118, which includes translations fromtype information to identifiers for plug-ins. (For purposes of thisdetailed description, a plug-in is executable code that can be added toan application program that is able to share a window with theapplication program.) Tables 116 and 118 may take the form of a HelperApplication Table, which is a table inside of a browser that maps typeinformation for a composite message to application programs that areable to process the composite message.

Mediator 120 is an application program, or a plug-in that forwardscommunications to application 112 on application server 104. Mediator120 communicates with table 122, which contains translations from typeinformation to addresses for remote applications, such as application112 on application server 102.

The system illustrated in FIG. 1 operates as follows. First, a useroperating web browser 114 on client 108 initiates some type oftransaction with web server 110 on server 102. In response, web server110 sends a composite message across network 106 to web browser 114.(For purposes of this detailed description, a composite message can beany type of data transfer across a network that includes one or moretransmissions. A composite message may include, but is not limited to, asingle document, a collection of documents, a single message, amulti-part message, a single file or a set of files.) Next, web browser114 reads type information from the composite message in order todetermine what type of composite message has been received from webbrowser 114. This type information may be determined by looking at anextension on the filename for a file associated with the compositemessage (For example a ".txt" extension may indicate a file containingASCII text). Alternatively, the type information may be read from acomposite message header, such as a Multipurpose Internet MailExtensions (MIME) type header. (MIME is a standard for type informationappended to a composite message, including information specifying howinformation within the composite message is formatted and/orpartitioned.) Next, the type information is used to lookup anapplication or a plug-in that is able to process the composite message.This lookup may be performed by accessing table 116, which containstype-to-application translations, or by accessing table 118, whichcontains type-to-plig-in translations.

If the type information specifies a client application, such as awallet, with an implementation on a remote server, the composite messageis sent to mediator 120. Mediator 120 uses the type information to lookup an address of the application on the remote server in table 122,which contains type-to-address translations. In one embodiment of thepresent invention, this address of a remote application includes aUniversal Resource Locator (URL). The composite message is thenforwarded to the application on the remote server. Optionally, thecomposite message can be forwarded within an appropriate protocol to itto make it appear as if it originated from a client application onclient 108.

Alternatively, if the type information specifies a client applicationthat exists on client 108, the composite message is sent to the clientapplication directly.

DESCRIPTION OF ANOTHER EMBODIMENT

FIG. 2 illustrates a distributed computer system in accordance with asecond embodiment of the present invention. In this embodiment, insteadof using a separate mediator 120 to forward the composite message toapplication 112 as in FIG. 1, web browser 114 performs the forwardingitself. In this embodiment, web browser 114 is modified so that it canstore type-to-address translations in tables 116 and 118. If the typeinformation specifies a client application, such as a wallet, with animplementation a remote server, the corresponding entry in either table116 or 118 contains a remote address for the application. In this case,the composite message is sent to the remote address. Alternatively, ifthe type information specifies a client application that exists onclient 108, the composite message is sent to the client applicationdirectly.

METHOD OF OPERATION

FIG. 3 is a flow chart illustrating some of the operations involved inforwarding communications to an application on a remote serveraccordance with an embodiment of the present invention. The systemstarts at state 300 and proceeds to state 302. In state 302, the systemreceives a composite message. In the embodiment illustrated in FIG. 1,this corresponds to web browser 114 in FIG. 1 receiving a compositemessage from web server 110 on server 102. This composite message can bein response operations performed by a user of client 108 in accessingweb server 110 through browser 114. Next, the system proceeds to state304. In state 304, the system reads type information from the compositemessage. This type information specifies how the composite message isformatted, and thereby implicitly specifies which application programscan read the composite message. This type information may be determinedby reading type information, which accompanies the composite message,such as MIME-type information. Alternatively, the type information maybe determined by reading a filename extension for a file associated withthe composite message. The system next proceeds to state 306.

In state 306, this type information is used to look up an address of anapplication on a remote server. In the embodiment illustrated in FIG. 1,this corresponds to mediator 120 looking up an address in table 122. Inthe embodiment illustrated in FIG. 2, this corresponds to web browser114, looking up an address in either table 116 or table 118. The systemnext proceeds to state 308.

In state 308, the system puts the composite message in appropriate formfor a second application. This may include modifying the compositemessage to make the composite message appear as though it originatedfrom a client computer system, instead of from web server 110. It mayalso include modifying the composite message to make the compositemessage appear as through it originated from another server. In oneembodiment of the present invention, this is accomplished by prependinghttp information onto the composite message. Next, the system proceedsto state 310. In state 310 the system forwards the composite message tothe address that was looked up in state 306. In the embodimentsillustrated in FIGS. 1 and 2, this corresponds to the composite messagebeing forwarded across network 106 to application 112 on applicationserver 104.

Although the above-illustrated embodiment of the present inventionillustrates a limited case where communications between a first servercomputer system and a client computer system are redirected to a secondserver computer system, these interactions can be generalized to largernumbers of server computer systems. For example, communications to anapplication on the client computer system can be redirected multipleserver computer system, wherein the multiple server computer systemseach handle portions of the client application program.

The foregoing descriptions of embodiments of the invention have beenpresented for purposes of illustration and description only. They arenot intended to be exhaustive or to limit the invention to the formsdisclosed. Accordingly, many modifications and variations will beapparent to practitioners skilled in the art. Additionally, the abovedisclosure is not intended to limit the invention; the scope of theinvention is limited only by the appended claims.

What is claimed is:
 1. A method for providing a client-side intermediarythat redirects communications directed to an application on a clientcomputer system to a remote application on a second server computersystem, comprising:receiving, at the client computer system, a compositemessage from a first server computer system directed to the applicationon the client computer system; examining type information from thecomposite message, the type information specifying how the compositemessage is formatted and thereby implicitly specifying applications thatare capable of processing the composite message; using the typeinformation to lookup the address of the remote application one thesecond server computer system that is capable processing the compositemessage; wherein the lookup is performed using at least one table thattranslates the type information into an address of the remoteapplication on the second server computer system; using the address toengage an access mechanism through which the remote application on thesecond server computer system can be accessed; and forwarding thecomposite message and subsequent composite messages of the same type tothe remote application on the second server computer system using theaccess mechanism so that the remote application appears to exist on theclient computer system in spite of the fact that the remote applicationactually exists on the second server computer system.
 2. The method ofclaim 1, further comprising:receiving, at the client computer system, areturn composite message from the second server computer system;examining return type information from the return composite message thereturn type information specifying how the return composite message isformatted and thereby implicitly specifying applications that arecapable of processing the return composite message; using the returntype information to engage a source access mechanism through which asource application on the first server computer system can be accessed;and forwarding the return composite message to the source application onthe first server computer system using the source access mechanism. 3.The method of claim 1, wherein:receiving the composite message includesreceiving the composite message at a browser on the client computersystem; and using the type information to look up the access mechanismincludes using MIME-type information to look up an entry in a helperapplication table in the browser, the entry in the helper applicationtable including the address of the application on the second servercomputer system.
 4. The method of claim 1, wherein:receiving thecomposite message includes receiving the composite message at aclient-side application on the client computer system; and whereinforwarding the composite message to the remote application to the secondserver computer system includes forwarding the composite message fromthe client-side application to the remote application on the secondserver computer system.
 5. The method of claim 1, wherein the typeinformation includes Multipurpose Internet Mail Extensions (MIME) typeinformation.
 6. The method of claim 1, wherein the type information isspecified by a filename extension for a file associated with thecomposite message.
 7. The method of claim 1, wherein forwarding thecomposite message to the remote application on the second servercomputer system, includes repackaging the composite message.
 8. Themethod of claim 1, wherein the address includes a Universal ResourceLocator (URL), and wherein engaging the access mechanism includesreferencing the remote application on the second server computer systemthrough the URL.
 9. The method of claim 1, wherein the remoteapplication implements an electronic wallet.
 10. A method for providinga client-side intermediary that redirects communications directed to anapplication on a client computer system to a remote application on asecond server computer system, comprising:receiving, at the clientcomputer system, a composite message from a first server computer systemdirected to the application on the client computer system; examiningtype information from the composite message, the type informationspecifying how the composite message is formatted according to theMultipurpose Internet Mail Extensions (MIME) standard and therebyimplicitly specifying applications that are capable of processing thecomposite message; using the type information to lookup the a UniversalResource Locator (URL) for the remote application one the second servercomputer system that is capable processing the composite message;wherein the lookup is performed using at least one table that translatesthe type information into an URL for the remote application on thesecond server computer system; using the URL to engage an accessmechanism through which the remote application on the second servercomputer system can be accessed; and forwarding the composite message tothe remote application on the second server computer system using theaccess mechanism; wherein the remote application on the second servercomputer system implements an electronic wallet.
 11. A computer readablestorage medium storing instructions that when executed by a computercause the computer to perform a method for providing a client-sideintermediary that redirects communications directed to an application ona client computer system to a remote application on a second servercomputer system, method comprising:receiving, at the client computersystem, a composite message from a first server computer system directedto the application on the client computer system; examining typeinformation from the composite message, the type information specifyinghow the composite message is formatted and thereby implicitly specifyingapplications that are capable of processing the composite message; usingthe type information to lookup the address of the remote application onethe second server computer system that is capable processing thecomposite message; wherein the lookup is performed using at least onetable that translates the type information into an address of the remoteapplication on the second server computer system; using the address toengage an access mechanism through which the remote application on thesecond server computer system can be accessed; and forwarding thecomposite message and subsequent composite messages of the same type tothe remote application on the second server computer system using theaccess mechanism so that the remote application appears to exist on theclient computer system in spite of the fact that the remote applicationactually exists on the second server computer system.
 12. An apparatusthat provides a client-side intermediary that redirects communicationsdirected to an application on a client computer system to a remoteapplication on a second server computer system, comprising:a receivingmechanism that receives a composite message from a first server computersystem directed to the application on the client computer system; areading mechanism, in communication with the receiving mechanism, thatreads type information from the composite message, the type informationspecifying how the composite message is formatted and thereby implicitlyspecifying applications that are capable of processing the compositemessage; an access mechanism, in communication with the readingmechanism, that uses the type information to trigger an access to theremote application on the second server computer system; wherein theaccess mechanism is configured to use the type information to lookup theaddress of the remote application one the second server computer systemthat is capable processing the composite message; wherein the lookup isperformed using at least one table that translates the type informationinto an address of the remote application on the second server computersystem; and a forwarding mechanism, in communication with the receivingmechanism, that forwards the composite message and subsequent compositemessages of the same type to the remote application on the second servercomputer system using the access mechanism so that the remoteapplication appears to exist on the client computer system in spite ofthe fact that the remote application actually exists on the secondserver computer system.
 13. The apparatus of claim 12, wherein:thereceiving mechanism is configured to receive a return composite messagefrom the second server computer system; the reading mechanism isconfigured to read return type information from the return compositemessage the return type information specifying how the return compositemessage is formatted and thereby implicitly specifying applications thatare capable of processing the return composite message; the accessmechanism is configured to use the return type information to trigger anaccess to a source application on the first server computer system; andthe forwarding mechanism is configured to forward the composite messageto the source application on the first server computer system using theaccess mechanism.
 14. The apparatus of claim 12, further comprising abrowser on the client computer system, the browser including thereceiving mechanism, the reading mechanism, the access mechanism and theforwarding mechanism.
 15. The apparatus of claim 12, further comprisinga client-side application on the client computer system, the client-sideapplication including the receiving mechanism, the reading mechanism,the access mechanism and the forwarding mechanism.
 16. The apparatus ofclaim 12, wherein the type information includes Multipurpose InternetMail Extensions (MIME) type information.
 17. The apparatus of claim 12,wherein the type information is specified by a filename extension of afile associated with the composite message.
 18. The apparatus of claim12, wherein the forwarding mechanism is configured to repackage thecomposite message.
 19. The apparatus of claim 12, wherein the addressincludes a Universal Resource Locator (URL), and wherein the accessmechanism references the remote application on the second servercomputer system through the URL.
 20. The apparatus of claim 12, whereinthe remote application implements an electronic wallet.
 21. A computersystem that provides a client-side intermediary that redirectscommunications directed to an application on a client computer system toa remote application on a second server computer system, comprising:aclient computer system; a first server computer system; a networkcoupled to the first server computer system, the second server computersystem and the client computer system; a receiving mechanism thatreceives a composite message from a first server computer systemdirected to the application on the client computer system; a readingmechanism, in communication with the receiving mechanism, that readstype information from the composite message, the type informationspecifying how the composite message is formatted and thereby implicitlyspecifying applications that are capable of processing the compositemessage; an access mechanism, in communication with the readingmechanism, that uses the type information to trigger an access to theremote application on the second server computer system; wherein theaccess mechanism is configured to use the type information to lookup theaddress of the remote application one the second server computer systemthat is capable processing the composite message; wherein the lookup isperformed using at least one table that translates the type informationinto an address of the remote application on the second server computersystem; and a forwarding mechanism, in communication with the receivingmechanism, that forwards the composite message and subsequent compositemessages of the same type to the remote application on the second servercomputer system using the access mechanism so that the remoteapplication appears to exist on the client computer system in spite ofthe fact that the remote application actually exists on the secondserver computer system.
 22. An apparatus that provides a client-sideintermediary that redirects communications directed to an application ona client computer system to a remote application on a second servercomputer system, comprising:a receiving means, for receiving a compositemessage from a first server computer system directed to the applicationon the client computer system; a reading means, in communication withthe receiving means, for reading type information from the compositemessage, the type information specifying how the composite message isformatted and thereby implicitly specifying applications that arecapable of processing the composite message; an access means, incommunication with the reading means, that uses the type information totrigger an access to the remote application on the second servercomputer system; wherein the access means uses the type information tolookup the address of the remote application one the second servercomputer system that is capable processing the composite message;wherein the lookup is performed using at least one table that translatesthe type information into an address of the remote application on thesecond server computer system; and a forwarding means, in communicationwith the receiving means, for forwarding the composite message andsubsequent composite messages of the same type to the remote applicationon the second server computer system using the access means so that theremote application appears to exist on the client computer system inspite of the fact that the remote application actually exists on thesecond server computer system.
 23. A method for providing a client-sideintermediary that redirects communications directed to an application ona client computer system to a remote application on a second servercomputer system, comprising:receiving commands from a user at a clientcomputer system; allowing the user to interact with a first servercomputer system through the client computing system; in response tointeractions by the user, receiving a communication directed to theclient computer system from the first server computer system; examiningthe communication to determine what type of information is contained inthe communications and thereby implicitly specifying applications thatare capable of processing the composite message; using the typeinformation to lookup the address of the remote application one thesecond server computer system that is capable processing the compositemessage; wherein the lookup is performed using at least one table thattranslates the type information into an address of the remoteapplication on the second server computer system; using the address toengage an access mechanism through which the remote application on thesecond server computer system can be accessed; and if the type ofinformation in the communication can be processed by the remoteapplication on a second server computer system, forwarding thecommunication to the remote application on the second server computersystem so that the remote application appears to exist on the clientcomputer system in spite of the fact that the remote applicationactually exists on the second server computer system.
 24. The method ofclaim 23, wherein the remote application on the second server computersystem implements an electronic wallet.
 25. The method of claim 23,wherein forwarding the composite message to the remote application onthe second server computer system includes repackaging the compositemessage.
 26. The method of claim 25, wherein repackaging the compositemessage makes the composite message appear to originate from the clientcomputing system.
 27. The method of claim 25, wherein repackaging thecomposite message makes the composite message appear to originate from athird server computing system.